IBIS Macromodel Task Group Meeting date: 01 February 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara * Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Michael said he had discovered a possible complication related to the [Clock Pins] keyword. He suggested that he could introduce the issue if time permitted. - Michael said he had received lots of feedback about his presentation on extending [Test Data] to support AMI. He said he would start a BIRD draft. ------------- Review of ARs: - Fangyi to review Walter's draft of BIRD 211.4. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 25th meeting. Randy moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: PAMn BIRD213.1: Walter said he had no new updates or feedback to report. Ambrish said he was still reviewing it. Randy said he had found a few typos in the most recent draft and would report them to Walter. Walter said he would post a new draft addressing Randy's comments and would await any comments from Ambrish. Randy asked people to review the BIRD in anticipation of voting to submit it to the Open Forum. AMI Root Name Clarifications BIRD draft: Michael shared the latest draft he had sent to the ATM list. He said it incorporated a change proposed by Mike LaBonte. Mike had noted that previous language referring to the "first ... line" in an AMI file was non-sensical because the entire contents of the .ami file could reside on one line. Michael said his suggestion was that the parser could call the executable model functions and issue a warning if there is a mismatch between what the model returns and the .ami file's root name. He acknowledged that this would be a non-trivial upgrade to the parser, as it does not currently call any of the executable model functions. Arpad said he thought the definition of "root name" as it pertains to what is in the .ami file was okay now. However, he said we might need to enhance the definition to include a statement about the value that is "hard-coded" in the executable model. Arpad said the BIRD's new text in the AMI_parameters_out section could be interpreted as saying that the model should return the value that was passed into it. He said we need to make it clear that the model itself contains a hard-coded value that must match the root name of the .ami file. Michael suggested we could add the phrase "which shall be contained within the executable model" to refer to the value returned by the model and address Arpad's concern. Randy agreed and noted that one tool he used to create AMI models hard-coded the root name in the executable model, and if it were passed the wrong root name from an .ami file it would fail. Randy said he had some editorial suggestions. He and Mike agreed to discuss them offline. Issue with the flexibility of [Clock Pins]: Michael said he had run into an issue while trying to create a model that used the [Clock Pins] keyword. He reminded everyone that it is currently an open ended keyword that associates pins with pins. The first column of each row is a clock pin, and the second column is a clocked pin that uses the first pin (it might be a data pin, or another clock, etc.). The third column can only contain "Unspecified" for now and is reserved for future use. Michael said his goal in introducing [Clock Pins] had been to give EDA tools a hint about these clocking relationships. This might allow them to automate certain set-up steps. For example, IBIS 7.1 includes AMI changes for clock- forwarded architectures and allows one AMI model to get its clock from another AMI model. The problem is that this clock-data association can't be specified at the AMI level. We want the association at the IBIS [Pin] level. For example, [Clock Pins] might help an EDA tool automate setup of a bus simulation with clock and data waveforms being simulated simultaneously and passed through the flow. Michael said he had run into an issue because these clock-data associations might vary depending on device configuration. For example, a x4 DDR configuration might do data and strobe associations by nibble, where a x8 configuration used the same strobe for an entire byte. So the clocking relationships between pins would be different for x4 or x8 configurations. Arpad asked if this was something that could happen in real time or was fixed by the device's configuration. Michael said a controller might expect to operate differently depending on the DRAM devices it's connected to. Randy said when they build memory it can be x4 or x8 and be the same piece of Si in the same package, but they will sell it as x4 or x8 by blowing fuses or some other physical change to lock it into one configuration. So, that clock-data relationship would be fixed for a given device. At run time the system figures it out by reading an EEPROM on the DIMM that stores the configuration information. Randy said when they create IBIS models, they use separate [Component]s for the x4 and x8 configurations. Since the [Clock Pins] keyword occurs inside the [Component], the clock-data relationships defined by the [Clock Pins] keyword are fixed. Michael observed that if you're a DRAM manufacturer this works fine, but if you're a controller manufacturer it might not ;-) Arpad wondered if we might consider having multiple named instances of [Clock Pins] keyword information. Then a particular instance could be selected for a given simulation/configuration. Michael said this would be something like a [Model Selector] approach. Arpad said it was similar to [EMD Group]s. Michael also suggested adding a 4th column to [Clock Pins] rows, which could could serve as the selector. Arpad said this was more like a [Series Switch Group] approach, and he thought this was more cumbersome and repetitive than having multiple instances of [Clock Pins]. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to send out a new draft of BIRD213.1 addressing Randy's comments. ------------- Next meeting: 08 February 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives